This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.

This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.

This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.

This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.

This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.

This commit replaces `all_asset_variants_uploaded?` with a simpler
`asset_uploaded?` method for both images and attachments. Instead of
requiring all variant files (e.g. `s960`, `s300`, etc.) to be present
before allowing publishing or previewing, we now consider the asset
“ready” if the original file has successfully uploaded.

In practice, all variants are generated and uploaded within milliseconds
of the original upload, and failures nearly always stem from the original file
itself. For example, if Asset Manager has an outage or detects a virus in
the uploaded asset, then the original variant will fail to successfully
upload, just as the variants will not. If the original variant has
successfully uploaded, then we can be highly confident (though can't
_guarantee_) that its variants will have to. The minimal risk hypothetical
edge case is a risk we can live with to allow for the following benefits:

* Supports content with partial variant sets (we will be importing news
  articles from Content Publisher, which have only the `s960` and `s300`
  variants).
* Enables future support for dynamically generated variants (e.g. via
  Fastly image resizing) without requiring full variant pre-generation.
* Greatly simplifies the codebase and removes brittle assumptions.

See alphagov/content-publisher#3311 (comment)
for a discussion on the different variant sizes and where they're
used.

As you can see in this commit, there is a lot of room for improvement
and consolidation across Whitehall. We have several implementations
of `asset_uploaded?` that are identical across modules. In practice,
most of these implementations were already only checking for the
'original' variant, and have now been simplified to make that
absolutely explicit. We should revisit this commit later to
consider how to extract some of this behaviour out into a shared
module so that we're not duplicating identical logic in multiple
places.